When developing parallel software or multi-threaded software, it is necessary to ensure correctness, for example with regard to errors such as data races and deadlocks. A common method here is to dynamically analyze a program at the runtime.
Existing tools operate with instrumentation, that is to say the program is changed, which, however, greatly influences both the timing and the storage requirement of the application. This may result in problems, particularly in the embedded field. On the one hand, the limited resources in the target system, for example the main memory, may make an analysis impossible and, on the other hand, the time behavior of the software is often essential, with the result that influence by the instrumentation here prevents the application from being able to be executed properly and an analysis is therefore invalid.
Under certain circumstances, it is possible, to a limited extent, to execute the software on a different platform. However, especially in the embedded environment, software often operates with external input/output devices which are available only on the actual target platform. Execution in a different environment therefore restricts the possibilities of meaningful test cases.
Previous tools for dynamically analyzing correctness operate as pure software solutions and are based on instrumentation of the program code, the instrumentation being effected either statically at the compile time, by means of special compiler plug-ins or modules or dynamically at the execution time. The result of the instrumentation is a change in the target program in such a manner that, if particular events occur, corresponding input data are generated for the analysis algorithm. Relevant events in this case are, for example, read and write memory access operations and function calls, in particular calls of memory management functions and calls of functions with respect to concurrency. In this case, an analysis algorithm uses the events which have occurred and their sequence to discern whether problems such as deadlocks or race conditions can occur in the program. Frequently used algorithms are “lockset” and “happens-before”, or else hybrid solutions which combine aspects of both approaches.
The most well-known tools of this type are:                Intel Inspector XE: dynamic instrumentation with PIN, analysis using a hybrid/proprietary algorithm        Helgrind (open source): dynamic instrumentation with the aid of the Valgrind framework, analysis using a happens-before algorithm        Google Thread Sanitizer (open source): static instrumentation by means of compilers, analysis using a hybrid algorithm        Oracle Thread Analyzer: static or dynamic instrumentation, analysis using a hybrid algorithm.        
The most important disadvantage of the instrumentation-based solutions is the overhead which arises at the runtime for the analysis. In this case, the execution of the application is slowed down by up to a factor of 50 and the memory usage for the analysis is also sometimes very high with several hundred MB.
There are trace solutions which are able to record program execution in detail by means of hardware support without changing the runtime properties of the target system. In this case, they use special interfaces which are provided by the processors, for example Nexus (in the case of a power architecture) or CoreSight (in the case of an ARM architecture). In order to access this information, a special device is generally needed in order to decode the trace streams from the CPU, supported by software on the host which further processes and conditions the data. These techniques are used in the embedded environment in the field of the debugging of real-time systems. Some of these solutions also already shape the dynamic analysis, but are restricted to profiling and coverage analysis.